1. Field of the Invention
This invention relates to a method for determining an interruption source, and more particularly, the invention relates to a test method for determining an interruption source, which is issued by an integrated drive electronics device.
2. Description of Related Art
The integrated drive electronics (IDE) device is nowadays commonly used as a peripheral device of a computer system, such as the hard disk drive or the CD/DVD-ROM optical disc drive. In the personal computer system, each of the IDE buses can be used to connect two IDE devices, which are respectively positioned at a primary bus of the IDE bus and a secondary bus of the IDE bus. Since the command set being used is different, The IDE devices can also be divided into types of the ATA device and the ATAPI device. The ATA device is for example a hard disk device, and the ATAPI device for example is CD/DVD-ROM optical disc drive, optical rewriteable disc drive, or ZIP disk drive. The command set that is used to access the ATA device, is the ATA command, and the command set that is used to access the ATAPI device, is the ATAPI command. As shown in FIG. 1A, it is a drawing, schematically illustrating a command flow diagram for proceeding the data access from the host to the IDE device. In FIG. 1A, the IDE device is a type of the ATAPI device, and the command set being used is the ATAPI command. Also referring to FIG. 1B at the same time, it is a drawing schematically illustrating an action flow diagram of the IDE device for responding to the commands made by the host. At the first, the host issues a pre-command to the IDE device. This pre-command is a content of 0xA0 in the ATAPI command, as shown in the step 102. As the IDE device receives this pre-command, as shown in the step 104, then it is checked to know whether or not the IDE device is busy, as shown in the step 106. If it is not busy, then an interruption is issued so as to inform the host, that the IDE device is ready to receive commands, as shown in the step 108. When the host receives the interruption from the IDE device, then the host issues an access command to the IDE device, as shown in the step 110. This access command is a packet command with a size of 12 bytes, and is used, for example, to read data from IDE device or to write data into the IDE device. When the IDE device receives the access command issued by the host, then the access command is executed, as shown in the step 112. For example, the data of the IDE device is read out and is stored in the buffer region. After that, an interruption, indicating the access being ready, is issued as shown in the step 114. When the host receives the interruption for access-ready, then the host starts to access the IDE device, as shown in the step 116. After the access is finished, the IDE device issues again an interruption for stopping the command, as shown in the step 118.
When the IDE device being developed, it needs a test program to perform a test on the IDE device. At this stage, this IDE device is called a testing IDE device. The test program includes a simulation program and a testing interruption service routine (ISR). All of the interruptions issued by the IDE device are intercepted by the testing ISR. The simulation program issues a command to the testing IDE device, which in turn responds to an interruption. The testing ISR intercepts this interruption for performing the testing process and then returns again to the simulation program. However, if the testing IDE device and another standard IDE device are respectively connected to the same IDE bus at the master position and the slave position, then the testing ISR can not discern which IDE device issued the received interruption, and therefore it cannot be known whether or not a testing process is necessary. The solution in the conventional method is, for example, that before the simulation program is to issue the command to the testing IDE device, a flag is asserted beforehand. Also, after the testing ISR receives the interruption, it first goes to check this flag to see whether or not the flag has been asserted. If it is, the interruption being received is issued from the testing IDE device. The test program is operated under the Microsoft disk operation system (MS-DOS) in real mode. In the real mode, it can only access a memory device with a size of 640K bytes. If a larger memory device needs to be accessed, then it should enter the protected mode. The memory device cannot be shared in the protected mode and in the real mode.
However, the testing IDE device could be issuing the interruption under the real mode or the protected mode, but the simulation program does execute and set up the flag under the protected mode. If the testing IDE device issues the interruption under the real mode, the testing ISR will not be able to detect flag set by the simulation program, thereby it cannot be judged whether or not the interruption is issued by the testing IDE device.